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1.0 


EXECUTIVE  SUMMARY 


1.1  Background 

Management  of  the  Defense  Intelligence  Agency  (DIA)  Information  System 
(DIS)  development  process  and  post-deployment  support  of  continuing 
operations  is  a  complicated  process.  It  involves  interactive  management  and 
coordination  among  the  users,  the  DIS  Segment  Managers,  individual  Project 
Managers,  and  those  charged  with  integration  management  (DS-SIMO).  The 
DIA  Director  of  Information  Systems  (DS)  and  the  Systems  Integration 
Management  Office  (DS-SIMO)  must  be  able  to  assess  the  impact  of  each  new 
system  or  each  change  to  an  existing  application  as  it  is  being  developed  and 
as  it  enters  the  operational  environment  to  effectively  balance  the  demands 
of  DIA  needs  with  increasingly  limited  resources.  They  must  maintain 
cognizance  of  schedules,  costs,  security  issues,  testing,  training  and 
maintenance  needs,  as  well  as  the  impact  on  resource  requirements  and 
operational  capabilities. 

The  complexities  of  the  current  and  planned  environments  can  best  be 
characterized  by  the  myriad  of  developers,  schedules,  interfaces, 
dependencies  and  differences  in  technical  design.  The  complications 
associated  with  managing  current  status  within  this  environment  are 
hindered  by  the  non-standard  and  manual  means  of  communicating  and 
coordinating  among  project  managers  and  to  senior  management.  This 
situation  is  further  complicated  by  the  diversity  of  automation  tools  used  to 
manage  status  at  the  project,  segment  and  system  levels.  Consequently,  the 
development  and  implementation  of  common  terminology,  definitions,  and 
standards  within  a  structured  integration  management  methodology  has 
become  imperative.  Focusing  on  interfaces  and  project  dependencies  to 
facilitate  communications  and  coordination  among  end  users,  developers  and 
acquisition/procurement  organizations  is  also  imperative.  To  do  this 
effectively  requires  consolidating  as  much  integration  management 
information  as  possible  into  a  single  integration  management  system.  An 
Integrated  Scheduling  System  (ISS)  is  the  first  step  in  implementing  such  a 
capability. 
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1.2  Accomplishments 

1.2.1  Data  Collection  and  Analysis 

Science  Applications  International  Corporation  (SAIC)  completed  the  initial 
data  collection  and  analysis  on  71  DIS  projects  comprising  17  functional 
segments  in  July,  1990  with  monthly  updates  continuing  through  March, 
1991.  A  dBase  IV  data  base  contains  all  project  milestones  and  dependency 
relationships  defined.  From  this  source,  17  DIS  Master  Segment  Schedules, 
the  DIS  Project  Interdependency  Schedule  and  the  DIS  GFE/GFI 
Interdependency  Schedule  graphically  portray  baselined  milestones  and 
dependencies.  This  DIS  Summary  Status  Report  and  17  Segment  Status 
Assessments  reflect  the  DS-SIMO  assessed  health  of  the  projects,  segments, 
and  the  DIS  in  the  aggregate.  The  real  point  and  value  of  this  data  collection 
and  analysis  activity,  however,  was  in  establishing  the  basis  for  the  DIA-ISS 
requirements  in  support  of  integration  management  needs. 

SAIC  supported  four  special-interest  projects  during  this  period  of 
performance.  For  the  Communications  and  Message  Processor  (CAMP),  the 
National  Military  Intelligence  Center  (NMIC)  Support  System  (NSS) 

Termination,  the  DIA  On-line  System  (DIAOLS)  Termination  and  the  Virtual 
Memory/eXtended  Architecture  (VM/XA)  Implementation  projects,  the 
emphasis  was  on  transitioning  into  or  out  of  operational  status.  An 

intensively  applied  methodology  focused  on 

a.  Identifying  project  objectives,  constraints  and  strategies, 

b.  Decomposing  projects  to  their  lowest  contributing  activity 
(four  levels  deep  for  DIAOLS  and  VM/XA), 

c.  Collecting  and  analyzing  cost,  schedule,  technical 

performance,  interface  and  dependency  data, 

e.  Adjusting  strategies  and  deconflicting  dependencies, 

f.  Developing  integrated  schedules  to  best  meet  the  objectives 
within  the  given  constraints,  and 

g.  Determining  accountability  for  every  event  requiring 
closure. 
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As  a  result,  those  projects  were  brought  under  control  and  testify  to  the  value 
and  necessity  of  integration  management  in  a  complex  environment.  It 
reduces  uncertainty  and  risk  while  producing  results  that  senior  management 
likes. 

1.2.2  Integration  Management  Requirements  Analysis 

The  data  analysis  results  were  iteratively  evaluated  using  the  SAIC- 
developed  Information  Systems  Integration  methodology  and  an  initial  set  of 
DIA-ISS  requirements  were  identified.  A  Project  Management  Dynamics 
Model  and  System  Integration  Dynamics  Model  were  successively  applied  to 
evaluate  the  relationships  of  cost,  schedule  and  technical  performance  within 
a  project’s  life  cycle  plus  interfaces  and  dependency  relationships  among 
multiple  projects  when  viewed  from  a  systems  integration  perspective.  This 
exercise  enabled  SAIC  to  identify  strengths  and  weaknesses  at  the  project 
management  and  integration  management  levels  that  needed  to  be 
accommodated  within  the  DIA-ISS  structure  and  prioritized  for 
implementation. 

To  aid  in  requirements  analysis  and  to  evaluate  implementation  alternatives, 
SAIC  developed  dBase  IV  code  called  SIMOCODE  and  a  supporting  data  base 
structure  called  SIMODATA.  The  success  of  this  approach  led  to  the  decision 
to  document  the  DIA-ISS  data  base  management  system  (DBMS) 
requirements  as  the  Software  Requirements  Specification  for  the  SIMOCODE 
Project  and  includes  the  supporting  data  base  structure  called  SIMODATA. 

1.2.3  Integration  Management  System  Alternatives  Analysis 

Two  DIA  decisions  made  just  prior  to  starting  the  period  of  performance 
directly  affected  the  scope  and  direction  of  this  task.  Adhering  to  the  DIA/DS 
policy  that  automated  support  tools  must  be  on  the  DIA  list  of  supported 
products  coupled  with  a  DS-SIMO  decision  to  use  the  dBase  III+  DBMS  and 
Project  Workbench  software  as  the  project  management  application  greatly 
refocused  this  effort.  Consequently,  SAIC  employed  these  automated  tools, 
subsequently  identified  limitations  experienced  in  supporting  the  DS-SIMO 
mission,  and  recommended  a  move  to  the  dBase  IV  DBMS  and  the  Lotus 
Freelance  Plus  graphics  capability  in  the  short  term.  When  the  source  code 
stabilizes,  implementation  of  Clipper  is  recommended  over  dBase  IV  until  a 
fully  integrated  data  base  and  graphics  generation  application  is  available. 
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These  recommendations  are  fully  consistent  with  the  DIS  Architecture  for  the 
1990’s,  the  DIS  Architecture  Standards  and  Products,  and  DIA/DS  policy. 

In  addition,  SAIC  delivered,  as  a  by-product  of  the  requirements  analysis 
effort,  a  working  prototype  of  SIMOCODE  and  SIMODATA.  SIMOCODE  and 
SIMODATA  can  support  DS-SIMO  near  term  integration  management  needs  in 
a  standalone  environment. 

1.3  Omissions 

The  System  Integration  Management  Plan  and  Automated  Information 
System  (AIS)  Project  Managers  Handbook  were  drafted  wholly  by  DS-SIMO 
government  personnel  prior  to  the  start  of  SAIC’s  period  of  performance. 
Consequently,  no  measurable  effort  was  expended  in  preparing  these 
documents. 

Because  of  the  changing  nature  of  the  project  list,  the  differences  in 
terminology  used  across  DIA  organizations,  and  the  inconsistent  use  of  project 
level  details  among  project  managers,  SAIC  suspended  project  analysis  efforts 
focused  on  mapping  milestone  data  into  a  predefined  standard  set  of 
milestones  prior  to  populating  the  prototype  data  base.  Consequently,  the 
time  and  resources  required  to  maintain  the  currency  of  project  data  already 
collected  was  reduced  permitting  the  use  of  those  resources  to  support 
requirements  synthesis  and  data  base  design  efforts. 

1.4  Assessment 

SAIC  proved  that  their  Information  Systems  Integration  methodology  works 
in  the  DIS  environment  and  does  so  at  relatively  low  cost.  The  initial 
priorities  were  focused  on  project  schedule  and  interproject  dependency 
management  of  and  designed  to  provide  DS  with  an  integrated  assessment  of 
the  DIS.  Consequently,  the  DS-SIMO  now  possesses  a  profile  of  schedule  and 
dependency-based  integration  management  requirements  looking  nine  to 
eighteen  months  in  the  future.  Armed  with  this  and  the  experience  gained 
over  the  past  fifteen  months,  DS-SIMO  is  well  postured  to  assess  future 
operational  resource  requirements. 

Especially  germane  to  this  assessment  is  the  experience  with  the  four  special- 
interest  projects  cited  earlier.  The  resulting  benefits  were  directly 
proportional  to  how  successfully  each  project  was  defined  and  accountability 
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established  with  respect  to  its  integration  requirements.  Fundamental  to  this 
process  was  the  DS-SIMO  commitment  of  government  and  SAIC  resources  to 
proactively  support  the  project  and  line  managers  in  identifying  the 
milestones  and  dependencies  required  for  strategy  definition  and  schedule 
baselining.  Only  rudimentary  automated  tools  were  used  and  then  primarily 
for  generating  briefing  aids.  The  real  value  added  was  the  application  of  an 
informed  and  structural  analysis  process  at  the  grass  roots  level  to  redefine 
the  projects  from  a  systems  perspective. 

1.5  Recommendation 

Two  primary  conclusions  were  drawn  from  the  experience  of  the  last  fifteen 
months.  First,  DS-SIMO  should  revalidate  its  fundamental  assumptions,  make 
the  requisite  adjustments  and  codify  the  new  direction  in  terms  of  a  concept 
of  operations.  Second,  more  progress  toward  institutionalizing  the 
methodology  is  needed.  SAIC  recommends  increasing  the  DS-SIMO  proactive 
involvement  in  data  collection  and  analysis  as  the  best  strategy  to  employ 
since  that  was  the  basis  of  its  integration  management  successes  and 
governed  the  most  project,  segment  and  line  managers  support. 
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2.0 


INTRODUCnON 


2.1  Purpose 

This  task  documented  requirements  for  an  Integrated  Scheduling  System 
(ISS)  to  satisfy  integration  management,  planning  and  scheduling 
responsibilities  of  DIA/DS.  The  ISS  will  be  the  primary  tool  used  by  the  DS- 
SIMO  as  it  focuses  on  interfaces,  dependencies  and  integration  among  the 
projects  and  segments  comprising  the  DIS. 

Because  of  the  need  to  ensure  that  the  project  management,  technical  design, 
fielding  and  integration  of  all  DIS  projects  provide  DIA  the  opportunity  to 
optimize  the  use  of  assets  in  meeting  mission  requirements,  DS-SIMO  is 
charged  with  improving  the  accuracy  and  scope  of  information  needed  to 
support  the  system  integration  management  function.  SAIC  worked  closely 
with  DS-SIMO  and  other  DS  staff  elements  to  ensure  the  ISS  requirements 
were  focused  on  DIS  integration  management  needs. 

2.2  Background 

Management  of  the  DIS  development  process  and  post-deployment  support  of 
continuing  operations  is  a  complicated  process.  It  involves  interactive 
management  and  coordination  among  the  users,  the  DIS  segment  managers, 
individual  project  managers  and  those  charged  with  integration  management 
on  a  daily  basis  (DS-SIMO). 

Currently,  DIS  segment,  project  and  integration  managers  use  both  manual 
and  limited  automated  tools  to  manage  the  development  and  operational 
support  projects  within  the  DIS.  Determining,  coordinating  and 
communicating  current  status  to  each  other  and  to  senior  management  within 
this  environment  is  understandably  hindered.  Consequently,  development 
and  implementation  of  common  terminology,  definitions  and  standards  within 
a  structured  integration  management  methodology  has  become  imperative. 
Focusing  on  interfaces  and  project  dependencies  to  facilitate  communications 
and  coordination  among  end  users,  developers  and  acquisition/procurement 
organizations  is  also  imperative.  The  ISS  provides  the  first  step  in 
implementing  such  a  capability. 
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2.3 


Scope 


This  effort  was  to  aid  DS-SIMO  in  identifying  requirements  and 
recommending  alternatives  for  implementing  an  ISS  within  the  DIA.  This 
included: 

a.  Identifying  DIS  integration  management  requirements; 

b.  Collecting  and  analyzing  data  on  designated  DIS  projects, 
their  dependencies,  and  interfaces; 

c.  Developing  a  data  base  concept  and  structure  focused  on 
unique  DIA  requirements;  and 

d.  Reviewing  or  analyzing  government-owned  and 
commercially  available  capabilities  with  respect  to  satisfying 
DIA  requirements. 

The  results  of  subtasks  a,  b,  and  c  above  are  documented  in  paragraphs  3.0 
and  4.0  of  this  report  and  in  the  Software  Requirements  Specification  (SRS) 
for  the  SIMOCODE  Project  which  includes  the  supporting  data  base  structure 
called  SIMODATA.  When  validated  by  the  government,  these  requirements 
will  form  the  basis  for  a  fully  operational  DIA-ISS  capability.  A  by-product  of 
this  effort  was  a  working  prototype  of  dBase  IV  code  (SIMOCODE)  and  its 
supporting  data  base  structure  (SIMODATA).  SIMOCODE  and  SIMODATA  were 
first  employed  in  day-to-day  support  to  DS-SIMO  in  July  1990. 

The  results  of  subtask  d  above  are  documented  in  paragraph  5.0  of  this 
report. 

2.4  Objectives 

This  task  had  two  major  objectives.  The  first  was  to  apply  SAIC’s  experience 
in  integration  management  and  in  developing  the  Air  Force  Strategic  Air 
Command  Intelligence  Data  Handling  Integration  Management  System  and  the 
Rome  Air  Development  Center  Project  Management  System  to  the  projects 
and  planned  automation  environment  defined  as  the  DIS  and  to  synthesize 
functional  requirements  for  an  ISS  for  DS-SIMO.  The  second  objective  was  to 
identify  and  document  system  requirements  for  an  automated  DIA-ISS. 
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3.0 


DATA  COLLECTION  AND  ANALYSIS 


3.1  Methodology 

3.1.1  Scope 

SAIC  conducted  initial  data  collection  and  analysis  activities  for  the  71  DIS 
projects  identified  from  January  1990  through  July  1990  for  the  purpose  of 
establishing  project  and  integration  management  baselines.  Figure  3.1,  DIS 
Segments,  reflects  the  current  projects  constituting  the  DIS.  The  long  term 
goal  is  to  establish  comprehensive  baselines  defined  by  cost,  schedule, 
technical  performance,  interfaces  and  dependency  parameters.  However,  the 
short  term  focus  was  on  schedules  and  dependencies  with  cost,  technical 
performance  and  interface  parameters  limited  to  specific  cases  when  the  data 
was  readily  available  or  critical  to  the  integration  of  the  project  within  the 
DIS.  Recurring  data  collection  and  analysis  continued  through  the  end  of  the 
contract  period  for  the  purpose  of  baseline  maintenance  and  integrity.  A 
variety  of  techniques  were  employed  for  the  data  collection  effort  ranging 
from  interviews  with  each  project  manager  to  the  review  of  documentation 
and  participation  in  technical  and  management  forums.  The  desktop  analysis 
that  followed  focused  on  identifying  technical  interface  and  schedule 
dependency  information  and  determining  compliance  with  the  DIS 
Architecture  and  DIA  policy/directives.  For  four  of  these  projects,  short  term, 
intensive  integration  management  techniques  were  employed.  Paragraph 
3.2.5,  Special-Interest  Project  Support,  documents  this  specialized  support. 

3.1.2  Assumptions 
SAIC  assumed  that: 

a.  Segment  managers  would  play  a  proactive  role  in  DIS 
integration  management.  They  would  provide,  at  a 
minimum,  a  first  level  integration  “reasonableness”  check  on 
project  and  interdependency  data  being  forwarded  to  DS- 
SIMO  for  their  segment. 
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FIGURE  3.1  -  DIS  SEGMENTS 


b.  DIS  projects  had  designated  DIS  project  managers  that  were 
knowledgeable  of,  or  practiced  in,  basic  project  management 
disciplines  i.e.,  managing  to  cost,  schedule  and  technical 
performance  baselines,  and  consequently,  could  provide  the 
data  to  be  collected. 

c.  Consistent  with  the  DS-SIMO  operational  and  management 
philosophy  of  “push  data  collection,”  data  would  be 
forthcoming  from  the  project,  segment  and  line  managers  on 
a  recurring  basis  once  the  initial  baseline  was  established. 
Thus  minimal  DS-SIMO  and  SAIC  effort  would  be  expended 
for  insuring  data  currency. 

d.  The  government  would  complete  most  of  the  project  related 
data  collection  with  SAIC  effort  focused  primarily  on  data 
analysis. 

3.1.3  Constraints 

Adhering  to  the  DIA/DS  policy  that  automated  support  tools  must  be  on  the 
DIA  list  of  supported  products  coupled  with  a  DS-SIMO  decision  to  use  the 
dBase  III+  DBMS  and  Project  Workbench  software  as  the  project  management 
application  significantly  impacted  productivity  for  the  first  six  months.  The 
capability  to  generate  automated  data  collection  and  dependency  analysis 
reports  were  foregone  until  SAIC  had  redeveloped  the  capability  in  dBase. 

3.2  Findings 

3.2.1  DIS  Data  Collection 

3. 2.1. 1  Initial  Data  Collection 

SAIC  initially  used  a  set  of  standard  project  milestone,  dependency  and 
interface  data  collection  forms  developed  by  DS-SIMO  for  this  activity.  These 
forms  (Attachment  1)  worked  very  well  for  collecting  data  from  the  few  well 
established  projects  under  contractor  development.  However,  for  the 
remainder  of  the  projects  these  standard  forms  inhibited  communication  and 
subsequently  saw  limited  use  as  a  prompting  vehicle  supporting  an  open 
interview  process  for  general  data  gathering.  A  “twenty-questions”  technique 
was  employed  for  focusing  attention  on  critical  project  milestones  and 


identifying  schedule  dependencies.  Some  raw  data  was  obtained  from  the 
review  of  project  or  program  management  plans,  workplans,  schedules, 
specifications,  interface  documents,  top  level  architectures  and  test  plans, 
however,  data  captured  from  these  sources  were  generally  a  by-product  of 
SAIC’s  analysis  effort  as  opposed  to  raw  data  collection. 

Once  the  data  points  were  verified.  Project  Workbench  files  were  populated. 
They  provided  a  rudimentary  capability  to  support  future  data  collection, 
dependency  analysis,  plus  requirements  synthesis  and  data  base  design. 
Using  these  methods,  the  SAIC  and  government  team  completed  the  initial 
data  collection  in  July  1990  at  which  time  schedule  and  dependency  baselines 
were  established  for  all  DIS  projects.  Figure  3.2  depicts  the  completed 
Segment  Baselining  Schedule  which  drove  the  initial  data  collection  effort. 


nCURE  3.2  -  SEGMENT  BASELINING  SCHEDULE 


3. 2. 1.2  Recurring  Data  Collection 


Concomitant  with  the  initial  data  collection  effort  was  the  additive  support  to 
the  growing  data  maintenance  task  for  previously  baselined  projects.  The 
scope  of  this  support  was  completely  underestimated  by  the  government 
because  the  project,  segment  and  line  managers  did  not  embrace  the  “push 
data  collection”  philosophy  as  expected.  Consequently  additional  recurring 

data  collection  initiatives  were  required  to  maintain  data  currency  and 

integrity.  These  initiatives  included 

a.  Generating  formal  staff  tasking  for  the  data  required, 

b.  Scheduling  additional  interview  sessions, 

c.  Providing  tutorial  briefings  to  encourage  more  active 

participation,  and 

d.  Proactive  data  collection  and  analysis  of  DIS  projects 

distributed  by  segment  across  the  total  DS-SIMO 
(government  and  SAIC)  staff. 

Only  the  last  initiative  provided  significant  and  consistent  results  (40%  return 
per  hours  expended),  whereas  the  remainder  provided  approximately  a  15% 
return  per  hours  expended.  Under  the  distributed  concept,  SAIC  assured  care 
and  feeding  of  four  segments  comprised  of  fifteen  DIS  projects. 

One  of  the  early  tools  used  to  enhance  recurring  data  collection  efforts  was  a 
milestone  schedule  generated  from  the  Project  Workbench  data  base.  In  May 
1990,  SAIC’s  data  base  design  under  dBase  III+  (subsequently  updated  to 
dBase  IV)  progressed  to  the  point  that  it  could  better  support  recurring  data 
needs  than  could  continued  use  of  Project  Workbench.  Consequently,  a  single 
integrated  data  base  of  700  milestones  and  70  dependency  relationships  was 
generated  in  dBase  III+.  The  milestones  and  dependencies  were  manually 
verified,  reconciled  with  the  Freelance  graphic  representations,  coded  for 
dBase  data  entry,  manually  keyed,  and  reverified  for  proper  entry  in  dBase. 
Subsequently,  SAIC  generated  dBase  milestone  schedules  and  dependency 
reports  to  prompt  recurring  data  collection.  Collectively,  these  reports 
identify  every  milestone,  dependency  and  independency  in  the  data  base  and 
provide  a  relatively  easy  mechanism  for  soliciting  data  base  updates.  SAIC 
suggested  this  method  be  employed  since  very  few  project/segment 


managers  were  forwarding  data  base  changes  for  their  respective  projects 
and  the  data  base  was  losing  currency.  These  reports  (on-line  and  off-line) 
remain  a  primary  means  for  communicating  data  collection  needs  to  project, 
segment  and  line  managers.  Samples  of  these  reports  are  at  Attachment  2. 

3. 2. 1.3  Cost/Resource  Data  Collection  Strategy 

3. 2. 1.3.1  Initiation 

SAIC  developed  an  initial  cost  data  collection  strategy  consistent  with  the 
integration  management  requirements  analysis  (Paragraph  4,0)  and  DS-SIMO 
near  term  goals,  and  prepared  the  briefing  given  by  DS-SIMO  at  the  12  June 
1990  SIMO  Segment  Review  kicking  off  the  data  collection  effort.  The  short 
term  strategy  focused  only  on  the  execution  phase  of  the  resource  life  cycle 
with  the  following  expected  benefits: 

a.  Assure  Project  and  DIS  Master  Schedule  stability, 

b.  Minimize  interproject  impacts, 

c.  Identify  candidate  projects  for  resource  reallocation,  and 

d.  Optimize  contract  and  government  resources. 

3.2. 1.3.2  Data  Sources 

Multiple  sources  of  data  were  recognized.  Contract  officers  technical 
representatives  (COTR)  had  access  to  contract  resource  data.  Project 
managers  generally  had  access  to  contract  resource  data  for  government 
technical  and  management  resources  which  were  dedicated  to  specific 
projects.  This  data  was  relatively  easy  to  capture.  The  most  difficult  to 
identify  and  therefore  capture  were  the  government  technical  and 
management  resources  not  dedicated  to  one  specific  project  but  matrixed 
across  many. 
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3.2. 1.3.3  DS-SIMO  Role 


The  DS-SIMO  role  was  two  pronged.  Initially,  DS-SIMO  would  task  Segment 
and  Matrix  managers  via  memoranda  requesting  two  levels  of  cost  and 
resource  data.  They  were 

a.  Planned  versus  actual  contract  costs,  and 

b.  Identification  of  key  government  people  so  that  task  loading  could 
be  managed  in  the  matrix  environment. 

Once  the  data  was  received,  DS-SIMO  would  add  value  by  assisting  the 
respective  managers  establish  realistic  cost/resource  baselines,  by  helping  to 
manage  the  baselines  as  configuration  management  items  under  DS 
Configuration  Control  Board  (DS-CCB)  auspices,  and  by  assisting  in  cost 
rebaselining  as  required. 

3. 2. 1.3. 4  Project,  Segment,  and  Matrix  Manager  Roles 

The  Project,  Segment  and  Matrix  Managers’  roles  in  this  strategy  were  to 

a.  Determine  cost  and  resource  baseline  requirements  and  then 
budget  and  allocate  resources  to  meet  the  requirement, 

b.  Establish  the  realistic  cost  baselines  necessary  to  successfully 
execute  the  project  by  identifying  cost,  technical  and  schedule 
adjustments  to  be  applied  to  ihe  current  baselines,  and 

c.  Manage  to  the  newly  adjusted  cost  baseline  by  measuring  and 
reporting  actual  resources  expended  against  the  baseline. 

3.2.2  DIS  Data  Analysis 

Whereas  data  collection  activities  varied  with  respect  to  initial  or  recurring 
collection,  data  analysis  activities  remained  relatively  constant  recognizing, 
however,  that  certain  projects  warranted  more  scrutiny  than  others.  Drawing 
from  experience  gained  from  the  Strategic  Air  Command  and  the .  Rome  Air 
Development  Center  efforts,  SAIC  decomposed  projects  to  their  lowest 
supporting  functional  activities  and  identified  critical  project  milestones  and 
interproject  dependencies  using  the  templates  in  Figures  3.3  and  3.4. 
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ISS  FUNCTIONAL  ACTIVITIES 


FIGURE  3 J  -  ISS  FUNCTIONAL  ACTIVITIES 


ISS  SYbTEM  MILESTONES 


FIGURE  3.4  -  ISS  SYSTEM  MILESTONES 


Armed  with  this  project  level  data  and  knowledge  of  the  many  standard 
milestones  having  inherent  intra  and  interproject  dependencies,  SAIC 
analyzed  this  aggregate  of  information  with  respect  to  each  project’s 
operating  environment  to  identify  additional  DIS  dependency  information  not 
readily  apparent  to  the  project  managers.  In  addition,  any  deviations  from 
the  DIS  Architecture  were  identified  for  further  analysis  or  adjudication.  The 
depth  of  the  analysis  provided  was  directly  proportional  to  the  level  of 
project  risk  and  management  interest,  with  the  four  special-interest  projects 
receiving  the  most  comprehensive  analysis  and  enjoying  the  most  stable 
schedules. 

Regardless  of  the  depth  of  analysis  applied  to  a  given  project,  every  project 
received  a  vertical  or  self-analysis  to  determine  its  health  with  respect  to 
meeting  cost,  schedule,  and  technical  performance  requirements.  Then  every 
project  was  analyzed  with  respect  to  interfaces  and  interproject  dependencies 
to  determine  its  health  from  a  DIS  or  system  integration  perspective. 

Initially,  the  Gantt  charting  and  critical  path  analysis  capabilities  of  Project 
Workbench  were  attempted  but  were  not  well  suited  to  event  or  milestone 
driven  analysis.  Consequently,  SAIC  relied  on  normal  analysis  techniques 
prior  to  the  dBase  implementation. 

3.2.3  DIS  Schedules 

3.2.3. 1  Structure 

SAIC  used  the  Lotus  Freelance  Plus  Release  3.01  graphics  capability  to 
generate  schedules  of  the  project  milestone  and  dependency  data  collected, 
analyzed  and  resident  in  the  data  base.  Approximately  30  charts  were 
revised  on  a  monthly  or  as-required  basis  to  reflect  fact-of-life  and 
anticipated  changes  to  the  approved  schedule  baselines.  All  were  produced 
according  to  the  hierarchical  relationship  depicted  in  Figure  3.5  and  are  a  key 
component  of  the  DS  System  Integration  Notebook. 
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HGURE  3.5  -  DIS  SCHEDULE  HIERARCHY 


Though  currently  a  labor  intensive  process,  thorough  dependency  analysis  is 
significantly  impacted  without  graphic  representation  of  the  data.  Graphic 
representation  also  supports  quality  assurance  since  a  data  error  is  much 
more  likely  to  be  recognized  graphically  than  by  textual  review  alone.  A 
synergy  of  analysis  and  data  point  quality  assurance  (QA)  is  also  realized. 
Experience  over  this  period  of  performance  shows  a  considerable  synergy 
between  analysis  and  QA  when  the  analyst  knowledgeable  about  the  data  and 
its  context  within  a  project  and  the  DIS  generates  and  updates  the  respective 
schedules. 
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3.2. 3. 2 


DIS  Master  Schedules 


At  the  top,  the  DIS  Master  Interdependency  Schedule  collates  all  interproject 
dependencies  identified  throughout  the  DIS  into  a  system  view.  In  order  to 
accommodate  the  potential  number  of  dependencies,  the  DIS  Project 
Interdependency  Schedule  portrays  only  project-to-project  dependencies.  It 
is  complemented  by  the  DIS  Government  Furnished  Equipment/Information 
(GFE/GFI)  Interdependency  Schedule  portraying  all  dependencies  between 
government  organizations  (DIA  or  external)  and  DIS  projects.  This  breakout 
also  focuses  attention  on  whether  a  project  manager  or  line  manager  is 
responsible  for  completing  a  dependent  milestone.  The  first  schedules  were 
produced  in  February  1990  and  have  been  updated  on  a  monthly  and  as- 
required  basis. 

3. 2. 3. 3  Segment  Schedules 

The  next  subordinate  level,  the  Segment  Schedule,  collates  into  a  segment 
view  the  key  milestones,  intra-segment  dependencies  and  all  interproject 
dependencies  for  its  functional  projects.  The  initial  Segment  Schedules  were 
generated  according  to  the  Segment  Baseline  Schedule  (Figure  3.2  page  10). 
All  dependencies  among  functional  projects  are  displayed  within  a  white 
band  across  the  center  of  the  chart.  Interproject  dependencies  external  to  the 
segment  are  identified  by  project  or  GFI  labels  and  displayed  in  shaded  bands 
at  the  top  and  bottom  of  the  chart.  Currently  17  Segment  Schedules 
composed  of  71  projects  are  being  updated  on  a  monthly  and  as-required 
basis. 

3. 2. 3. 4  Project  Schedules 

The  Project  Schedule  provides  the  next  level  of  detail  and  has  been  generated 
only  for  special-interest  projects,  i.e.,  CAMP,  DIAOLS  Termination  and  VM/XA 
Implementation.  A  single  format  has  been  used  but  with  tailored  headings. 
When  focusing  on  the  external  or  interproject  dependencies,  the  project 
column  lists  other  projects  for  which  dependencies  are  displayed.  When 
including  internal  or  intraproject  dependencies,  the  project  column  (now 
labeled  Project/Subproject)  also  lists  subordinate  project  tasks  for  which 
dependencies  are  displayed. 
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3. 2. 3. 5  Subproject  Schedule 

The  Subproject  or  Functional  Activity  Schedule  extends  the  flexibility  of  this 
graphic  format  another  level.  The  subproject  represented  by  a  single  line  on 
a  Project  schedule  is  now  further  decomposed  into  its  constituents. 

3. 2. 3. 6  Examples 

This  format  supports  any  level  of  schedule  portrayal.  The  levels  of  depth  of 
data  collection  and  analysis  and  subsequent  graphical  representation  by  this 
format  are  strictly  dependent  on  the  level  of  decomposition  and  detail 
required  to  manage  the  specific  integration  problem.  Current  examples  of 
these  schedules  can  be  obtained  from  DIA/DS-SIMO. 

3.2.4  Status  Assessments  Reports 

3.2.4. 1  Structure 

Fundamental  to  the  Integration  Management  Requirements  Analysis 
(paragraph  4.0)  is  the  concept  of  system/segment/project  assessment  by  an 
independent  source,  in  this  case,  DS-SIMO.  To  support  such  a  requirement,  a 
series  of  status  assessment  reports  were  developed  using  Lotus  Freelance 
Plus  Release  3.01.  Each  is  produced  according  to  the  hierarchical  relationship 
depicted  in  Figure  3.6  and  corresponds  to  the  schedule  hierarchy  in  Figure 
3.4.  The  reports  are  designed  to  quickly  focus  management  attention  on 
projects/segments/organizations  having  internal  difficulty  and  more 
importantly,  the  potential  to  impact  others.  The  requisite  management 
attention  could  be  at  the  project,  segment,  line  or  corporate  level.  These 
reports  are  also  a  key  component  of  the  DS  System  Integration  Notebook. 
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SYSTEM  LEVEL  STATUS  REPORT 


GFE/GFl  STATUS  REPORT 


OTHERS 
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HGURE  3.6  -  DIS  STATUS  REPORT  HIERARCHY 


3. 2. 4. 2  System  Level  and  GFE/GFI  Status  Reports 


At  the  top,  the  System  Level  Status  Report  and  GFE/GFI  Status  Report  reflect 
the  assessed  status  of  the  DIS  as  depicted  in  the  DIS  Project  Interdependency 
Schedule  and  the  GFE/GFI  Interdependency  Schedule  respectively.  These 
reports  present  DS-SIMO’s  assessment  of  the  health  and  welfare  of  each  of 
five  attributes  for  each  segment  in  the  DIS.  The  cost,  schedule  and  technical 
attributes  reflect  the  collective  assessed  status  of  a  segment’s  projects, 
whereas  the  interface  and  dependency  attributes  reflect  the  collective 
assessed  status  of  the  segment  as  its  projects  relate  to  other  projects  and 
segments.  Each  attribute  is  assessed  as  being  Satisfactory,  Marginal, 
Unsatisfactory  or  Not  Baselined  and  are  color-coded  as  Green,  Yellow,  Red  and 
White  respectively.  Narrative  justification/comments  are  required  for  each 
instance  of  a  Marginal  and  Unsatisfactory  assessment. 
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3. 2. 4. 3  Segment  Status  Charts 


The  Segment  Status  Charts  reflect  the  assessed  status  of  the  segments 
depicted  in  the  respective  Segment  Schedules.  The  reports  present  DS-SIMO’s 
assessment  of  the  health  and  welfare  of  each  of  five  attributes  for  all  projects 
in  the  segment.  The  cost,  schedule  and  technical  attributes  reflect  the 
assessed  status  of  each  functional  project,  whereas  the  interface  and 
dependency  attributes  reflect  the  assessed  status  of  each  functional  project  as 
it  relates  to  other  projects.  Attribute  assessment  and  narrative  justification 
are  analogous  to  those  for  the  System  Level  Report. 

3. 2. 4. 3  Examples 

This  format  can  be  used  to  portray  the  assessed  status  at  any  level  chosen  but 
generally  corresponds  to  its  respective  schedule.  Current  examples  of  these 
charts  can  be  obtained  from  DIA/DS-SIMO. 

3.2.5  Special-Interest  Project  Support 

SAIC  intensively  applied  integration  management  techniques  to  four  special- 
interest  projects.  The  projects  are  CAMP,  NSS  Termination,  DIAOLS 
Termination  and  VM/XA  Implementation.  Though  all  were  DIS  baselined 
projects,  each  drew  focused  DIA/DS  attention  due  to  schedule,  dependency, 
cost  and  contractual  risk  if  those  projects  did  not  meet  transition  schedules. 
The  techniques  applied  were  the  same  techniques  applied  to  the  remainder  of 
the  DIS  projects,  only  the  emphasis  changed. 

For  those  four  projects,  the  emphasis  was  on  transitioning  into  or  out  of 
operational  status.  Therefore,  it  was  necessary  to  change  the  focus  from 
being  project  oriented  to  becoming  system  oriented.  Consequently,  each 
project  was  restructured  into  defacto  “Transition  Increments”  as  defined  in 
SAIC’s  Information  Systems  Integration  methodology  and  documented  during 
the  Integration  Management  Requirements  Analysis  (paragraph  4.2.1)  as  a 
requirement  for  DS-SIMO  implementation.  It  was  this  restructuring  of  the 
transitioning  project  into  a  DIS  view  that  changed  the  thought  process  and 
enabled  the  final  results. 

After  analysis  of  the  data  collected  for  NSS  Termination  and  CAMP,  each 
project  was  further  decomposed  to  establish  its  base  intraproject  dependency 
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set.  From  this  more  detailed  data,  additional  interproject  dependencies  and  a 
more  realistic  schedule  was  generated. 

For  the  DIAOLS  Termination  Project,  SAIC  helped  prepare  the  data  collection 
strategy,  analyze  data  collected,  structure  a  decision  briefing,  and  work  the 
post-briefing  actions.  A  comprehensive  and  achievable  schedule  of 
milestones  and  dependencies  defining  a  cost-effective  termination  strategy 
while  preserving  user  support  resulted. 

For  the  VM/XA  Implementation  project,  SAIC  helped  analyze  implementation 
requirements,  identified  and  deconflicted  dependencies,  and  developed  an 
integrated  schedule  to  include  VM/XA  subproject  tasks  for  accomplishing  the 
implementation  strategy. 

The  results  of  these  four  projects  testify  to  the  necessity  of  integration 
management  in  a  complex  environment.  When  applied  with  diligence  and 
accountability,  it  is  invaluable  in  properly  scoping  the  problem,  focusing 
effort  on  risk  areas,  eliminating  surprises,  and  producing  the  results  that 
senior  management  likes. 

3.2.6  Problems  Encountered 

3.2.6. 1  General 

Generally,  data  collection  and  analysis  shortfalls  were  predictable  in  type  but 
significantly  greater  in  scope  than  expected.  Data  base  currency  continues  to 
average  30  to  60  days  behind  calendar  date.  Contributors  to  this  situation  are 

a.  The  lack  of  feedback  on  scheduled  events  by  project  and 
segment  managers, 

b.  Project  managers  not  planning  future  milestones  and 
dependencies  for  their  projects,  and 

c.  Ambiguous,  inconsistent  and  uncoordinated  updates  when 
provided. 

The  effects  of  this  over  the  longer  term  are  numerous  and  significant  if  not 
checked.  First,  the  data  base  quickly  reduces  to  a  historical  repository, 
instead  of  an  active  integration  management  tool.  Second,  extraordinary  data 
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collection  efforts  are  required  of  DS-SIMO  and/or  line  managers  to  recover. 
In  some  instances  this  requires  total  project  rebaselining.  Third,  analysis 
time  and  resources  tend  to  grow  exponentially  in  an  effort  to  make  existing 
data  consistent,  clear  and  useful  to  management.  Unfortunately  this 
contributes  to  the  data  currency  problem.  Fourth,  continued  use  of  the  data 
base  as  an  integration  management  tool  by  managers  at  all  levels  is  directly 
proportional  to  the  confidence  in  the  data. 

3. 2. 6. 2  Dependency  Control  Document  (DCD)/Dependency  Reporting 

The  difficulty  in  understanding  the  concept  of  a  schedule  dependency  and 
confusion  with  interfaces  was  unexpected  and  is  still  evident.  Simply  stated, 
a  dependency  is  a  schedule  relationship  that  exists  when  one  event  or 
milestone  cannot  occur  or  be  completed  until  preceded  by  the  completion  of 
another  event  or  milestone.  If  these  relationships  are  wholly  within  a  project 
they  are  called  intraproject  dependencies.  Figure  3.7  illustrates  an 

intraproject  dependency. 

Intraproject  Dependency  Deflnition 


•  Definition  of  Intraproject  Dependency:  relying  on  another  for  support 


•  Milestone  B  relies  on  Milestone  A  to  deliver  some  sort  of  support 


Milestone  B  is  the  Dependent  Milestone 

Milestone  A  is  the  Independent  Milestone 
HGURE  3.7  -  INTRAPROJECT  DEPENDENCY  DEFINITION 

If  dependency  relationships  exist  between  or  among  projects  they  are  called 
interproject  dependencies  and  are  the  main  focus  of  integration  management 
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by  DS-SIMO.  A  more  detailed  discussion  of  dependencies  is  documented  in 
the  “Software  Requirements  Specification  for  the  SIMOCODE  Project”  produced 
for  DIA/DS-SIMO.  Figure  3.8  illustrates  an  interproject  dependency. 

Interproject  Dependency  Definition 

•  Definition  of  Interproject  Dependency:  relying  on  another  for  support 


•  Project  B  relies  on  Project  A  to  deliver  some  sort  of  support 


Project  B  is  the  Dependent  Project 
Project  A  is  the  Independent  Project 

HGURE  3.8  -  INTERPROJECT  DEPENDENCY  DEFINITION 

Because  of  the  difficulty  encountered  with  segment  and  project  managers 
identifying  and  coordinating  valid  dependencies,  SAIC  recommended  and  DS- 
SIMO  implemented  the  DCD  strategy  as  a  solution.  The  DCD  (Figure  3.9)  is 
intended  to  do  for  an  interproject  dependency  what  an  Interface  Control 
Document  does  for  project  interfaces,  i.e.,  unambiguously  document  the 
dependent  relationship  between  two  different  projects--one  the  dependent 
(or  needing/requiring)  project  and  the  other  the  independent  (or 
owing/supplying)  project. 


25 


Dependency  Control  Document 


DCD#: 

Date  Tasked: 
Date  Received: 


Project  Manager  Name:  Date  Signed: 

Project  Manager  Signature: 


FIGURE  3.9  -  DEPENDENCY  CONTROL  DOCUMENT 
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It  documents  an  agreement  or  defacto  contract  between  two  project  managers 
based  upon  the  mutual  understanding  of  the  scheduled  requirement  and 
serves  as  a  concrete  basis  for  renegotiation  should  a  change  in  either  project’s 
schedule  or  deliverable  impact  the  dependency, 

SAIC  initiated  the  effort  by  briefing  the  strategy  at  the  June  12,  1990  SIMO 
Segment  Review.  The  DCD  was  subsequently  included  in  the  AIS  Project 
Managers  Handbook  which  requires  its  use  for  documenting  interproject 
dependencies.  Where  the  DCD  was  faithfully  used  by  project  managers,  the 
strategy  has  been  proven.  However,  success  has  yet  to  be  achieved.  The  day- 
to-day  benefits  of  the  DCD  have  not  been  recognized  by  project,  segment,  nor 
line  managers  and  consequently  has  not  been  institutionalized  within  the  DIS. 
SAIC  continues  to  believe  that  the  DCD  is  critical  to  interproject  dependency 
management  within  the  DIS. 

3. 2. 6. 3  Cost/Resource  Data  Collection  and  Analysis 

Only  scattered  response  was  achieved  by  the  cost/resource  data  collection 
effort.  Repeated  data  calls  provided  insignificant  results.  Consequently,  no 
analysis  of  cost/resource  data  was  performed. 

3.3  Assessment  and  Recommendations 

The  data  collection  and  analysis  experience  showed  that  the  “push  data 
collection  philosophy”  doesn’t  work  unless  managers  perceive  the  exercise  as 
mutually  beneficial  (not  just  another  senior  management  exercise  in  micro- 
management),  and  the  collection  process  is  a  byproduct  of  their  daily  routine 
as  opposed  to  an  added  requirement. 

In  the  cases  of  the  special-interest  projects,  data  collection  and  analysis 
became  mutually  supportive  of  DS-SIMO  and  the  respective  project  managers, 
but  data  was  not  automatically  forwarded  to  DS-SIMO  to  support  data  base 
update  requirements.  Generally,  a  more  proactive  approach  was  required  of 
the  DS-SIMO  staff  if  real  benefits  were  to  be  attained.  This  was  especially  so 
for  the  recurring  data  collection  requirements  across  the  DIS. 

The  recurring  data  collection  experience  also  suggested  that  all  projects  do  not 
require  the  same  level  of  attention,  especially  the  local  AISs.  Consequently, 
DS-SIMO  should  consider  employing  a  two  tiered  approach  for  recurring  data 
collection  and  analysis.  Priority  projects  could  constitute  one  tier  and  require 
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proactive  attention  while  second  tier  projects  could  continue  on  a  “push  data 
collection”  basis.  Such  an  approach  requires  acceptance  of  less  current 
schedules  for  second  tier  projects.  The  benefit,  of  course,  is  freeing  the 

limited  DS-SIMO  staff  to  focus  on  the  more  critical  integration  management 
needs. 

Project  data  volatility  strongly  suggested  that  many  projects  were  not 
properly  defined  and  that  many  efforts  assigned  to  the  “infrastructure”  could 
profit  by  a  project-orientation.  No  resources  need  to  necessarily  be 

reassigned  but  visibility,  scope  and  accountability  readjusted.  Projects  tend 

to  focus  on  endpoints  and  goals  with  accountability  leading  to  more 

disciplined  management.  On  the  other  hand,  infrastructure  activity  tends  to 
focus  on  the  process  which  subsumes  the  original  goals.  SAIC  found  that  the 
largest  set  of  dependencies,  those  for  which  it  was  the  hardest  to  determine 
responsibility,  and  those  most  likely  to  miss  their  scheduled  milestones,  were 
also  those  emanating  from  the  DS  infrastructure. 
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4.0 


INTEGRATION  MANAGEMENT  REQUIREMENTS  ANALYSIS 


4.1  Methodology 

4.1.1  Scope 

SAIC  conducted  an  Integration  Management  Requirements  Analysis  from 
January  1990  through  May  1990.  During  this  analysis,  SAIC  applied  the  the 
Project  Management  Dynamics  Model  and  System  Integration  Dynamics 
Model  (Attachment  3)  to  define  and  bound  the  scope  of  the  DS-SIMO 
integration  management  effort.  This  analysis  was  done  in  a  “story  board” 
format  to  allow  a  highly  interactive  process  between  SAIC  and  DS-SIMO  with 
rapid  turnaround.  The  final  result  of  this  process  was  documented  separately 
and  can  be  obtained  from  DIA/DS-SIMO. 

4.1.2  Analysis 

The  analysis  resulted  in  a  set  of  charts  depicting  the  types  of  reports  an 
integration  management  system  would  have  to  produce  to  meet  the  DS-SIMO 
mission.  These  reports  would  be  primarily  on-line  reports  with  an  analyst 
option  to  print  a  hard  copy.  On  sign-on,  a  system  user  would  be  advised  of 
his  open  action  items  and  be  given  a  menu  from  which  to  work.  The  open 
action  item  reports  would  list  those  action  items  for  which  the  person  signing 
on,  an  entire  segment,  or  a  project  was  responsible. 

The  system  level  status  report  was  designed  to  provide,  in  one  chart,  a 
comprehensive  status  of  all  the  segments  and  integration  management  areas 
for  the  DIS.  The  segment  level  status  report  showed  similar  data  for  the 
projects  in  a  segment  while  the  project  status  report  focused  on  one  project. 

As  part  of  helping  DS-SIMO  define  a  configuration  management  process,  the 
Baseline  Change  Request  (BCR)  Summary  chart  would  collect  BCR’s  at  the 
segment  level  and  at  the  project  level.  Separate  reports  provide  details  on 
the  five  areas  (Cost,  Schedule,  Technical,  Interfaces,  and  Dependencies) 
evaluated  for  each  project. 

4.1.3  Priorities  and  Constraints 

DS-SIMO  itself  was  limited  in  the  resources  it  could  apply  to  this  task  and, 
therefore,  established  priorities  for  developing  the  system  design  to  meet  the 
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identified  requirements.  The  first  priorities  were  to  develop  the  schedule  and 
dependency  reports  and  supporting  data  base.  That  data  base  was  to  have  a 
structure  to  allow  adding,  cost,  technical,  and  interfaces,  action  items,  and 
BCR’s  at  a  later  date.  SAIC  estimated,  and  DS-SIMO  concurred,  that  only 
schedule  and  dependency  tracking  could  be  completed  within  the  time  and 
resources  allocated  to  this  effort.  The  prototype  SIMOCODE  and  SIMODATA 
were  the  end  products  of  this  work. 

4.2  Assessment 

The  prototype  SIMOCODE  demonstrated  its  utility  for  tracking  milestones  and 
dependencies  throughout  the  DIS  and  particularly  for  the  four  special  interest 
projects  cited  in  paragraph  1.2.1.  It  also  focused  attention  on  the  need  to  plan 
for  transition  increments  (part  of  the  System  Integration  Dynamics  Model), 
interfaces  and  technical  performance. 

As  the  DIS  project  managers  began  to  see  the  value  added  by  the  DS-SIMO 
work  and  also  obtained  access  to  the  DS  LAN,  the  need  for  a  SIMOCODE  to 
support  LAN  access  also  grew.  Plans  to  accomplish  this  objective  were 
worked  outside  of  this  effort. 

SIMOCODE’s  success  at  DS-SIMO  brought  SIMOCODE  to  the  attention  of  the 
newly  formed  DODIIS-SIMO  in  November  1990  and  SAIC  advised  the  DODIIS- 
SIMO  staff  regarding  the  Project  Management  Dynamics  Model  and  System 
Integration  Dynamics  Model  and  their  application  to  the  DODIIS-SIMO 
environment.  The  result  was  a  joint  DS-SIMO/DODIIS-SIMO  evaluation 
briefed  by  SAIC  which  detailed  the  similarities  between  the  two  SIMO 
operations  and  outlined  an  approach  for  using  SIMOCODE  on  the  LAN  to  meet 
both  organization’s  needs.  The  recommended  approach  consisted  of  two 
phases.  Phase  1  was  to  convert  SIMOCODE  to  LAN  operation  and  evaluate 
SIMOCODE’s  utility  on-line.  This  phase  is  underway  as  this  report  is  being 
written.  Phase  2  will  use  the  on-line  prototype  to  build  the  joint  DS 
SIMO/DODIIS  SIMO  requirements  and  procedures  and  add  functionality  to  the 
SIMOCODE.  Contact  DIA/DS-SIMO  for  the  analysis  of  the  two  operations  and  a 
more  detailed  discussion  of  the  approach  for  SIMOCODE  to  meet  the  needs  of 
both  organizations. 
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5.0 


THE  INTEGRATION  MANAGEMENT  SYSTEM  ALTERNATIVES 
ANALYSIS  REPORT 


5.1  Methodology 

5.1.1  Scope 

SAIC  conducted  a  functional  and  technical  analysis  of  commercial,  off-the- 
shelf  (COTS)  data  base  manager  and  project  management  software  on  a 
continuing  basis.  The  analysis  was  based  on  the  results  of  the  DIA-ISS 
requirements  identified  by  the  Integration  Management  Requirements 
Analysis  effort  (Paragraph  4.0)  and  was  consistent  with  the  DIS  Architecture, 
DIA  Architecture  Standards  and  Products,  and  DIA/DS  policy.  Once  the 
product  base  was  chosen,  SAIC  translated  the  functional  requirements  into  a 
Software  Requirements  Specification  and  accompanying  Data  Base  Design 
Document.  These  documents  not  only  reflect  the  fully  operational  DIA-ISS 
requirement  baseline  but  also  document  the  working  prototype  delivered  as  a 
by-product  of  the  requirements  analysis  effort. 

5.1.2  Assumptions 

a.  SAIC  assumed  that  the  results  of  the  December,  1989 
undocumented  DS-SIMO  study  of  off-the-shelf  project 
management  software  and  data  base  management  systems 
are  valid  and  accepted  Project  Workbench  and  dBase  III+  as 
the  products  of  choice.  However,  non-  duplicative  analysis 
of  these  products  would  be  conducted  as  changes  to  DS- 
SIMO  requirements  and  COTS  product  lines  occurred. 

b.  Since  Data  Item  Descriptions  (DIDs)  were  not  specified,  SAIC 
selected  DI-MCCR-80025  A,  Software  Requirements 
Specification  (SRS),  29  Feb  1988,  for  documenting  DIA-ISS 
requirements  and  the  working  SIMOCODE  prototype. 

5.1.3  Constraints 

The  alternatives  analysis  could  only  consider  products  approved  for  the  DIA 
list  of  supported  products. 


5.2 

Findings 

5.2.1 

Product  Evaluation 

5. 2. 1.1 

Project  Workbench 

SAIC  populated  the  Project  Workbench  data  structure  for  use  as  a  data 

repository  and  to  support  analysis  plus  the  initial  graphics  generation  for 
SIMO  Segment  Reviews.  However,  as  the  scope  of  the  DS-SIMO  mission, 
became  clear  and  the  DIA-ISS  requirements  matured,  the  limitations  of 
Project  Workbench  began  to  surface.  Chief  among  these  were  its 

a.  Inability  to  handle  over  70  DIS  projects  simultaneously, 

b.  Inability  to  handle  intricate  dependency  relationships 

within  and  among  projects, 

c.  Inability  to  handle  technical  and  interface  data  between 

projects, 

d.  Inadequate  schedule  chart  formatting,  and 

e.  Restrictive  handling  of  cost  data. 

5. 2, 1, 2  Project  Management  System 

In  1989,  SAIC  delivered  a  prototype  Integrated  Scheduling  System  to  the 

Rome  Air  Development  Center,  Air  Force  Intelligence  Agency,  and  the 
Electronics  Systems  Division  of  the  Air  Force  Systems  Command.  This  system, 
entitled  Project  Management  System  (PMS),  and  patterned  after  the 
integration  management  system  operational  at  Strategic  Air  Command,  was 
developed  using  the  Advanced  Revelation  (AREV)  data  base  management 
system  for  IBM  compatible  platforms.  While  PMS  could  handle  intricate 
dependencies  and  a  large  number  of  projects  well,  it  did  not  address  technical 
performance  or  interfaces  nor  did  it  adequately  address  cost  when  compared 
to  DS-SIMO  stated  objectives.  Schedule  charts  were  produced  two  ways. 
Gantt  portrayals  were  plotted  directly  from  the  data  base  while  more 
intricate  graphics  were  produced  freehand  using  Macintosh  graphics 
capabilities.  DS-SIMO  did  not  support  SAIC’s  recommendation  to  use  the 
prototype  PMS  software  for  requirements  synthesis  and  daily  operations 
support  interim  to  a  DIA  standard  system  becoming  available.  The  use  of 
AREV  weighed  heavily  against  PMS  since  AREV  was  not  on  the  DIA  list  of 
supported  data  base  management  systems.  (See  paragraph  5. 2. 1.6  for  a 
discussion  of  Macintosh  products.) 
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5. 2. 1.3  Lotus  Freelance  Plus  Version  3.01 

Lotus  Freelance  is  a  DIA  standard  general  graphics  program  for  the  IBM 

personal  computer  (PC)  and  compatibles.  Frustrations  with  obtaining 
adequate  schedule  charts,  led  DS-SIMO  to  adopt  Freelance,  and  considera^^’e 
labor  hours  attendant  to  its  use,  as  the  method  for  producing  acceptable 
schedule  charts.  Automatic  generation  of  Freelance  quality  schedules  may  be 
available  soon.  In  the  April  1987  issue  of  the  International  Journal  of  Pattern 
Recognition  and  Artificial  Intelligence,  Freeman  and  Ahn’s  article,  “On  the 
Problem  of  Placing  Names  in  a  Geographic  Map,”  describe  an  automatic 

technique  for  producing  maps  from  a  digital  database  where  names  are 
placed  without  conflict  with  other  features.  This  problem  is  essentially  the 
same  as  the  schedule  generation  problem  and  may  well  be  directly  applicable. 

5. 2. 1.4  dBase  III+  and  dBase  IV 

dBase  is  a  standard  DIA  data  base  manager.  To  provide  a  point  of  comparison 
between  PMS/AREV  and  the  data  base  design  developed  for  this  type  of 
application,  SAIC  developed  a  set  of  dBase  files  and  data  to  demonstrate  the 
integration  management  data  base  concept.  This  concept  was  accepted  and 
SAIC  proceeded  to  develop  the  code  further  as  DS-SIMO  gained  more 
experience.  A  dBase  III+  limitation  is  its  inability  to  write  reports  to  a  file. 
dBase  IV  has  that  ability  and  was  selected  to  support  report  writing  that 
would  be  distributed  over  the  local  area  network  (LAN). 

5. 2. 1.5  Forms  Managers 

dBase  has  a  limited  ability  to  create  forms  for  reports  or  input.  Off-the-shelf 

forms  managers  that  interface  directly  with  dBase  files  are  available.  A  study 

of  capabilities  should  show  how  one  of  these  packages  can  be  added  to  the 
SIMOCODE  prototype  to  greatly  enhance  input  and  output  of  data.  Conduct  of 
this  study  is  premature  until  the  LAN  capable  SIMOCODE  prototype  has 
stabilized.  Similarly,  any  forthcoming  decision  on  a  DIA-ISS  final 
product/architecture  other  than  SIMOCODE  should  also  include  Forms 
Manager  evaluation  criteria. 
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5. 2.1. 6 


Macintosh  Products 


The  DIA  standard  personal  computer  is  the  IBM  family  of  compatibles.  This 
standard  precluded  considering  applications  directed  at  the  Macintosh 
architecture. 

5. 2. 1.7  SYNERGY 

SYNERGY  is  a  modular  project  control  system  developed  by  the  Bectel 
Corporation  using  the  ORACLE  data  base  management  system  (DBMS).  It  is 
comprised  of  14  modules  which  are  selectable  by  the  project  for  its  specific 
needs.  The  system  can  be  run  on  personal  computers  as  well  as  on  mini 
computers  and  mainframes.  Though  literature  research  showed  it  to  be  a 
very  comprehensive  capability,  DS-SIMO  directed  that  no  further 

investigation  or  analysis  be  undertaken  for  two  reasons; 

a.  The  DBMS  is  not  on  the  DIA  list  of  supported  DBMSs,  and 

b.  The  system  was  judged  cost  prohibitive.  Basic  start-up 

modules  are  priced  at  $6500  plus  an  annual  maintenance 

fee  of  $1300.  Each  additional  module  is  priced  at  $2500 
plus  an  annual  maintenance  fee  of  $500.  Even  with  a 
significant  price  discount,  SYNERGY  would  remain 

unaffordable. 

5. 2. 1.8  SYBASE 

SYBASE  is  a  distributed,  relational  DBMS  considered  for  the  ALE  project.  DS- 
SIMO  and  SAIC  attended  a  demonstration  meeting  in  Rosslyn,  Virginia  to 
determine  whether  SYBASE  could  accommodate  the  DS-SIMO  needs  should 
ALE  select  SYBASE  and  DIA  subsequently  adopt  SYBASE  as  a  DIA  standard. 

We  concluded  that  nothing  in  SYBASE  precluded  doing  the  dBase  IV  coded 
functions  on  this  system  as  opposed  to  any  other  DBMS.  In  some  respects,  the 
ability  to  establish  a  distributed  system  may  make  the  dBase  IV  coded 
system  easier  and  more  effective  because  the  individual  projects  would  have 
local  control  over  their  own  portion  of  the  data  base. 
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5. 2. 1.9  Clipper 


Clipper  is  a  dBase  compatible  system  that  allows  for  compiling  the  source 
code  into  execution  modules  that  run  very  quickly  and  without  the  need  for  a 
run-time  version  of  dBase.  (Run  time  modules  must  be  purchased.)  Clipper 
should  be  u.sed  to  compile,  configuration  manage,  and  distribute  dBase  IV 
code  when  the  source  code  stabilizes. 

5.2.1.10  Others 

As  the  DIA-ISS  matures  and  becomes  institutionalized,  requirements  tracing 
and  accounting  software  will  need  to  feed  the  DIA-ISS  data  base.  When  that 
time  comes  an  analysis  of  COTS  and  government-owned  software  should  be 
undertaken. 

5.3  Assessment 

Given  the  constraint  of  using  products  approved  for  the  DIA  list  of  supported 
products,  the  selection  of  dBase  IV  and  Freelance  on  the  IBM  compatible 
platform  should  satisfy  DIA-ISS  automated  requirements  for  the  foreseeable 
future.  Continued  search  for  a  COTS  or  government-owned  product  which 
integrates  data  base  functions,  analysis  tools  and  graphics  generation  is 
certainly  warranted.  However,  such  a  product  will  likely  not  be  on  the 
current  DIA  list  of  supported  products.  Regardless,  caution  is  advised  so  that 
the  sophistication  of  the  chosen  tools  does  not  generate  a  learning  curve  and 
data  loading  requirement  which  far  exceed  the  expected  benefit. 


35 


6 . 0  CONCLUSIONS  AND  RECOMMENDATIONS 

A  number  of  conclusions  are  drawn  which  SAIC  provides  in  prioritized  order. 

a.  Recommend  DS*SIMO  revalidate  its  fundamental 
assumptions  in  light  of  the  lessons  learned  over  the  past  15 
months,  make  the  requisite  adjustments  and  codify  that 
direction  in  a  Concept  of  Operations. 

b.  In  order  to  succeed  in  the  long  term,  the  methodology  must 
be  institutionalized,  i.e.,  it  must  be  accepted  and  supported 
by  the  project,  segment  and  line  managers.  Since  success 
tends  to  beget  success,  concentration  on  those  activities 
which  led  to  the  integration  management  successes  is  logical. 
Consequently,  more  proactive  involvement  in  data  collection 
and  analysis  by  DS-SIMO  is  recommended.  Not  only  will  this 
create  additional  short  term  successes,  but  it  will  reinforce 
the  tenet  that  DS-SIMO  is  a  positive  force  that  can  help  bring 
about  success. 

c.  Caution  is  recommended  in  the  continued  search  for 
automation  tools.  Overly  sophisticated  tools,  even  if 
inexpensive  and  fully  COTS,  may  carry  a  learning  curve  and 
data  loading  cost  that  may  far  exceed  the  expected  benefit. 
Though  not  fancy  nor  fully  integrated,  the  current  data 
bases  and  graphics  tools,  with  limited  enhancement,  could 
serve  the  DS-SIMO  until  such  time  that  the  data 
manipulation  and  presentation  requirements  are  validated 
with  respect  to  the  Concept  of  Operations. 

d.  The  System  Integration  Management  Plan,  AIS  Project 
Managers  Handbook,  and  Configuration  Management  Plan 
need  to  be  baselined,  published  and  distributed  as  soon  as 
possible.  Recommend  however,  that  a  progressive 
implementation  strategy  and  supporting  procedures  be 
developed  prior  to  distribution  of  the  Configuration 
Management  Plan.  The  DS-SIMO  currently  does  not  have 
the  resources  nor  the  procedures  to  support  the  full  scope  of 
the  plan.  Consequently,  a  “go-slow”  approach  consistent 
with  DS-SIMO  resource  demands  is  encouraged. 
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e.  DS-SIMO  Segment  Reviews  have  been  the  most  effective 
when  focused  on  DIS  integration  problem  solving.  In 
keeping  with  the  “success  begets  success”  theme,  issues 
which  do  not  meet  this  criteria  should  not  be  addressed  in 
this  forum.  They  take  an  inordinate  amount  of  time,  rarely 
come  to  concrete  resolution,  and  have  a  long  term 
deleterious  effect  on  participation  in  the  reviews. 

f.  The  commitment  of  staff  resources  to  work  with  the  DODIIS- 
SIMO  is  recommended  to  ensure  that  the  respective 
functional  and  system  requirements  are  as  convergent  and 
mutually  supportive  as  possible. 
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ATTACHMENT  1 


Data  Collection  Forms 

This  attachment  contains  a  set  of  standard  project  milestone,  dependency  and 
interface  data  collection  forms  initially  used  for  the  DIA-ISS  effort. 
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ATTACHMENT  2 
Data  Base  Report  Samples 

This  attachment  contains  samples  of  the  Project  Schedule,  Dependency  and 
Independency  Status  Reports  used  to  prompt  data  collection  and  support  DS- 
SIMO  analysis. 
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I2/DSNET  3  Schedule  Status  Report 
03/31/91 

Current 


i  lestone 

Baseline 

Est imate 

Actual 

Status 

520  (V5  -  O&M) 

/  / 

/  / 

/ 

/ 

NO  BASELINE 

All  site  TN3270  Access-DIA  IBM 

/  / 

/  / 

/ 

/ 

NO  BASELINE 

520  (VI  -  5  year'  plan) 

01/16/90 

02/01/90 

06/15/90 

COMPLETED 

520  (V2  -  Interop’bility  Test) 

01/16/90 

01/22/90 

06/01/90 

COMPLETED 

520  (V3  -  Ethernet  Conversion) 

01/16/90 

02/01/90 

06/01/90 

COMPLETED 

520  {V4  -  NTC  Contract  Support 

01/16/90 

02/01/90 

07/09/90 

COMPLETED 

Terminate  12  Circuits 

06/30/90 

08/15/91 

/ 

/ 

SLIPPED 

Finish  Modelling  (First  Phase) 

07/01/90 

07/01/90 

08/15/90 

COMPLETED 

Finish  NMIC  Gateway  Conversion 

07/31/90 

08/30/90 

08/30/90 

COMPLETED 

NTC  Upgrade  Engineering  Model 

08/01/90 

01/18/91 

/ 

/ 

OVERDUE 

Finish  Interop ' i 1 ity  Test  (V2) 

09/30/90 

09/30/90 

09/30/90 

COMPLETED 

Finish  Ethernet  Conversion( V3 ) 

09/30/90 

06/30/91 

/ 

/ 

SLIPPED 

Terminate  NTC  Contract  Support 

09/30/90 

06/30/91 

/ 

/ 

SLIPPED 

^  Year  Plan  Complete 

02/01/91 

02/01/91 

/ 

/ 

OVERDUE 

Complete  NTC  Upgrades 

03/31/91 

05/31/91 

/ 

/ 

SLIPPED 

TN3270  Access  to  COINS 

06/21/91 

06/21/91 

/ 

/ 

OK 

DIA  12  Shutdown 

08/31/91 

08/31/91 

/ 

/ 

OK 

Terminate  O&M  Contract  (V5) 

06/30/92 

06/30/92 

/ 

/ 

OK 

Finish  I2/DSNET  Conversion 

06/30/92 

06/30/92 

/ 

/ 

OK 

03/29/91/09:58:43 
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I2/DSNET  3  Dependency  Status  Report 
03/31/91 


ependent  Project 

Dependent  Milestone  Baseline  Current  Actual  Status 


12/DSNET  3 

DIA  12  Shutdown  08/31/91  08/31/91  /  /  OK 


Independent  Projects 

Independent  Milestone  Baseline  Current  Actual  Status 


DIAOLS 

Terminate  Ext  Online  Service 


03/31/91  03/31/91  /  /  IMPENDING 


03/29/91/10:16:15 
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I2/DSNET  3  Independency  Status  Report 
03/31/91 


Independent  Project 


idependent  Milestone 

Baseline 

Current 

Actual 

Status 

I2/DSNET  3 

TN3270  Access  to  COINS 

06/21/91 

06/21/91 

/  / 

OK 

Dependent  Projects 

Dependent  Milestone 

Basel ine 

Current 

Actual 

Status 

DIAOLS 

Terminate  Ext  Online  Service 

03/31/91 

03/31/91 

/  / 

IMPACT 

03/29/91/10:10:32 
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1 .0  Project  Management  Model 

This  attachment  describes  a  model  of  project  management  with  which  DIA-ISS 
requirements  were  evaluated  and  on  which  the  SIMOCODE  design  is  based. 

1.1  Introduction 

The  system  management  problem  has  many  dimensions  and  the  successful 
system  or  program  manager  (PM)  must  have  access  to  data  that  reflects  all 
facets  of  these  many  dimensions.  As  will  be  demonstrated  shortly,  the  system 
management  task  is  very  complex  and  very  dynamic.  Any  automated  system 
that  hopes  to  track  this  process  must  be  capable  of  handling  both  the  complexity 
and  the  dynamics  while  bringing  coherency  to  a  process  that  drives  toward 
incoherency.  In  addition,  many  systems  are  being  collected  into  systems  of 
systems.  The  development  of  local  and  wide  area  networks  allowed  previously 
standalone  systems  the  opportunity  to  communicate  with  other  systems. 
Initially  these  networks  only  served  as  a  communications  link.  Now,  however, 
the  trend  is  toward  the  network  using  the  synergistic  interactions  of  the 
subordinate  systems  to  provide  a  function  much  greater  than  the  sum  of  the 

subordinates.  Phasing  individual  system  modifications  and  upgrades  now 
becomes  a  significant  task.  The  manager's  need  for  useful  and  timely 

information  likewise  becomes  more  demanding. 

Central  to  any  management  information  system  (MIS)  is  data.  There  is  a 
tendency  for  MISs  to  require  the  project  management  team  to  spend  more 

energy  supplying  data  to  the  MIS  than  the  team  saves  because  of  the  MIS.  This 
tendency  leads  toward  old  and  unreliable  data  in  the  MIS  and  a  general  distrust 
and  eventual  disuse  of  the  MIS.  To  counteract  this  situation,  the  MIS  must 
provide  a  needed  product  to  every  member  of  the  program  management  team 
who  is  expected  to  keep  part  of  the  data  base  current.  The  design  of  such  a 
system  must  satisfy  the  needs  of  many  disciplines  and  be  usable  at  many  levels 
of  management.  A  model  of  project  management  that  is  applicable  to  the 
subsystem,  s-  tern,  or  system  of  systems  levels  is  the  Project  Management 

Dynamics  Model. 
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1.2 


Project  Management  Dynamics  Model 


The  Project  Management  Dynamics  Model  depicts  the  relationships  of  cost, 
schedule,  and  technical  performance  at  all  levels  and  at  all  phases  in  the  life  of  a 
project.  The  model  emphasizes  the  need  for  coherence  between  these  three 
attributes  throughout  the  life  cycle  of  the  system  and  uses  a  “three-armed 
balance”  analogy  to  show  these  relationships  (Figure  A3.1). 


Figure  A3. 1 

The  Three  Arm  Balance 
Model  of  Program 
Management 

Numerous  disciplines  and  a  variety  of  tools  provide  data  to  each  arm.  Likewise, 
each  arm  is  the  source  of  data  for  many  reports  required  of  the  project 
management  staff.  For  example,  the  cost  arm  receives  data  from  or  provides 
data  to  cost  estimating  techniques,  accounting  systems  that  track  funds  status 
through  budgets,  commitments,  obligations,  expenditures,  and  disbursements  by 
category  of  funds  and  fiscal  year.  Disciplines  and  tools  that  define,  allocate, 
trace,  test,  and  track  requirements  and  performance  throughout  the  life  of  the 
system  support  the  performance  arm.  Disciplines  and  tools  that  identify  and 
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track  schedule  milestones,  critical  paths,  and  dependencies  from  concept 
development  through  decommissioning  support  the  schedule  arm.  Figure  A3.2 
shows  an  array  of  disciplines  and  tools  supporting  the  three  arm  balance. 


Cost  Estimation  -  Baseline  Cost  Estimate 
Accounting  To  Support  Budget  Preparations 
Accounting  To  Support  Execution 


Three  Arm  Balance  Model 

1.2.1  Balancing,  Tipping  and  Rebalancing  the  Scale 

1.2. 1.1  Balancing  the  Scale  -  The  Program  BaseLine 

The  scale  is  balanced  when  cost,  schedule  and  technical  performance  are  all 
achievable  simultaneously  (Figure  A3.1).  When  balanced,  cost,  schedule  and 
technical  performance  at  this  level  are  said  to  be  coherent.  Ideally  this  is  the 
baseline  established  at  program  initiation.  As  the  program  progresses  and 
deviates  from  the  baseline,  variances  are  generated  which  act  as  weights  on  the 
arms  of  the  scale  causing  it  to  tip  (Figure  A3.3). 
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Figure  A3.3 

The  Three  Arm  Balance 
With  Variances 

1.2, 1.2  Tipping  the  Scale  -  Variances 

As  the  program  deviates  from  the  baseline  and  produces  variances,  these 
variances  act  like  weights  that  tip  the  scale.  How  much  weight  is  produced  by 
these  variances  is  regulated  by  the  difference  between  the  baseline  and  actual 
or  new,  current  estimates.  For  example,  suppose  an  important  design  review 
slips.  If  the  new  date  is  still  earlier  than  the  baseline,  the  trend  is  noted  but  no 
action  is  taken.  If  the  date  approaches  or  slips  past  the  baseline,  decisive  action 
is  needed.  Similar  arguments  apply  to  the  cost  and  performance  arms. 
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1.2. 1.3  Rebalancing  the  Scale  -  More  Variances 

Recovering  balance  requires  one  of  two  actions,  remove  the  initial  variance  or 
add  compensating  variances  to  the  other  arms.  Sometimes  a  variance  can  be 
spotted  quickly  and  its  cause  removed.  In  these  cases,  balance  can  again  be 
achieved  quickly  and  easily.  More  often,  however,  a  solution  is  more  elusive  or 
requires  more  drastic  measures  -  adding  variances  to  the  other  arms  to  recover 
balance.  The  following  examples  illustrate: 

a.  The  program  experiences  a  budget  cut.  The  cost  arm  now  has  a 
variance  and  the  relationship  of  cost  to  the  schedule  and 
performance  baselines  is  not  coherent.  Rebalancing  means 
eliminating  capability  (performance)  and  changing  schedule.  The 
new  baseline  may  reflect  unfunded  requirements  but  the  program  is 
balanced. 

b.  Preliminary  design  indicates  a  particular  performance  parameter- 
cannot  be  met.  Additional  cost  and  schedule  might  solve  the 
problem  as  will  a  lessening  of  the  requirement.  This  example  could 
be  the  result  of  a  poorly  designed  baseline  (it  wasn’t  balanced  in  the 
first  place)  or  poor  execution  of  a  proj'^’-ly  balanced  baseline  (the 
designer  was  incompetent). 

Notice  that  in  both  examples  a  balance  results  from  an  added  variance  on  all 
three  arms  (Figure  A3. 3).  After  many  perturbations,  these  accumulated 
variances  translate  to  cost  overruns,  late  deliveries,  and  below  standard 
performance  when  compared  to  the  original  baseline.  The  object  of  program 
management  is  to  maintain  balance  while  minimizing  the  variances. 

At  this  point  the  model  can  be  used  to  assess  risk  and  risk  reduction  actions.  By 
tracking  historical  trends  and  determining  sensitivities  to  those  trends,  high  risk 
and  high  sensitivity  combinations  can  be  mitigated  through  close  monitoring, 
redesign,  or  other  appropriate  action.  Adding  another  level  of  sophistication  to 
the  model,  e.g.,  transfer  functions  between  the  arms,  can  allow  the  PM  to  predict 
the  required  values  of  the  compensating  variances.  This  can  allow  automated 
support  to  “what  if’  analyses.  The  concept  of  transfer  functions  is  addressed  in 
Paragraph  1.4  of  this  attachment. 
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1 .3  System  Integration  Dynamics  Model 

The  Project  Management  Dynamics  Model  just  described  only  addresses  the 
dynamics  internal  to  the  project  being  developed.  When  integrated  into  a  larger 
system,  a  project  will  interact  in  some  way  with  other  projects.  Expanding  the 
project  management  dynamics  model  slightly  forms  the  basis  for  the  System 
Integration  Dynamics  Model. 

1.3.1  Interfaces 

Consider  two  projects  each  at  different  points  in  their  life  cycle.  The  project 
management  dynamics  models  may  look  like  Figure  A3 .4 

If  these  projects  will  eventually  produce  systems  with  a  formal  technical  or 
performance  link,  commonly  called  an  interface,  we  depict  that  interface  on  the 
model  by  joining,  the  two  technical  performance  arms.  This  signifies  that  the  two 
projects  have  interrelated  dynamics  on  the  technical  arms.  Now  when  one 
project  experiences  a  variance,  the  other  may  also.  The  degree  of  impact  on  the 
second  project  will  be  affected  by  many  parameters  to  be  discussed  shortly. 

1.3.2  Dependencies 

Now  suppose  there  is  no  interface  between  the  two  projects  but  one  still 
depends  on  the  other  for  some  service.  A  case  in  point  is  the  retirement  of  an 
aging,  hard  to  maintain  system  and  replacement  by  new  equipment  and 
software.  Before  the  old  system  can  come  down,  the  new  system  must  assume 
some  or  all  of  the  functions  of  the  old  system  as  well  as  demonstrate  any  new 
functions.  The  Project  Management  Dynamics  Model  depicts  this  relationship  as 
shown  in  Figure  A3.5. 

Now  the  projects  are  linked  at  the  schedule  arms  by  schedule  events  -  that  is, 
one  project  depends  on  another  for  a  function,  event,  or  item  before  the  first 
project  can  continue  its  life  cycle.  This  relationship  is  called  a  dependency.  The 
Independent  Project  is  the  one  providing  the  object  of  the  dependency  and  the 
Dependent  Project  receives  the  object  of  the  dependency.  In  our  example,  the 
aging  equipment  milestone  might  be  system  termination  (the  dependent 
milestone)  and  the  new  equipment's  initial  operational  capability  (IOC)  milestone 
might  be  the  independent  milestone.  If  the  new  equipment  experiences 
variances  that  delay  IOC,  the  aging  equipment  is  impacted  because  it  must 
remain  operational  longer  at  increased  program  costs  and  delay  in  schedule. 
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Two  Projects  With  An  Interface 


Cost 

Baseline 
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Interfaces  and  dependencies  are  documented  by  Interface  Control  Documents 
(ICDs)  and  Dependency  Control  Documents  (DCDs)  respectively.  The  details  of 
interfaces  and  dependencies  are  worked  out  in  interface  control  working  groups 
(ICWGs)  and  dependency  control  working  groups  (DCWGs). 

As  a  system,  particularly  a  network,  grows  in  capability  or  over  time,  the 
number  and  nature  of  projects  changes  as  do  the  number  and  nature  of 
dependencies  and  interfaces.  The  integration  manager  must  have  a  model  that 
helps  account  for  the  complex  dynamics  and  provides  a  measure  of  control  to  the 
network  upgrade.  This  is  provided  by  the  Transition  Increment  Dynamics 
Model. 

1.3.3  Transition  Increment  Dynamics  Model 

The  Transition  Increment  Dynamics  Model  (Figure  A3. 6)  depicts  the 
asynchronous  nature  of  the  numerous  program  schedules  comprising  a  larger, 
mega-system.  Individual  programs  may  be  ready  for  initial  or  upgraded 
operations  on  substantially  different  schedules.  Dependencies  and  interfaces 
will  determine  whether  and  to  what  extent  other  projects  are  impacted.  The 
Transition  Increment  Dynamics  Model  allows  maximum  possible  independence 
for  the  component  programs  while  assuring  the  mega-system  evolves  in  a 
beneficial  and  planned  manner. 

Transition  Increments  are  treated  as  programs  in  their  own  right  complete  with 
dependencies  but  generally  without  interfaces.  The  Transition  Increment 
manager  is  responsible  for  regression  testing,  integration,  and  similar  activities 
as  well  as  certifying  the  mega-system  upgrade  has  met  its  requirements  without 
adverse  impacts. 
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Transition  Transition  Transition 

Mega-System  Increment  Increment  Increment 

Figure  A3.6 

TRANSITION  INCREMENT  DYNAMICS  MODEL 

1.4  Project  Management  Development  Model  Extended  for  Large 

Programs 

Large  programs  are  characterized  by  two  or  more  projects  with  a  sophisticated 
set  of  performance  requirements,  a  budget  that  extends  over  several  years  with 
more  than  one  category  of  funding,  and  an  extensive  and  interrelated  set  of 
schedule  events.  Managing  these  programs  requires  the  PM  to  break  each  of 
these  areas  down  into  smaller,  easier  to  comprehend  pieces. 

1.4.1  Work  Breakdown  Structure 

Complex  programs  must  be  broken  into  small  pieces  to  facilitate  understanding 
and  tracking.  The  orderly  decomposition  of  the  total  project  into  small  pieces 


Program  1 
Program  2 
Programs 
Program  4 
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that  can  be  reliably  scheduled  and  costs  estimated  is  done  through  the  work 
breakdown  structure  (WBS).  These  bite-sized  pieces  will  each  have  a  technical, 
cost,  and  schedule  standard  associated  with  them.  The  program  then  manages 
total  performance,  cost,  and  schedule  through  the  levels  of  the  work  breakdown 
structure. 

1.4.2  Organizational  Breakdown  Structure  (OBS) 

Management  is  the  art  of  accomplishing  an  objective  through  other  people. 
Program  management  involves  an  organization  with  delegated  responsibilities. 
In  program  management,  assigning  logical  segments  of  the  work  breakdown 
structure  to  the  various  organizational  entities  works  best.  The  organization  is 
defined  to  a  management  information  system  by  the  organizational  breakdown 
structure  and  each  element  in  this  structure  is  assigned  one  or  more  segments  of 
the  work  breakdown  structure. 

1.4.3  Cost  Breakdown  Structure  (CBS) 

The  cost  arm  is  organized  according  to  a  cost  breakdown  structure  (CBS),  which 
is  then  applied  across  the  WBS.  The  CBS  tracks  past,  current,  and  future  costs  by 
category  and  year  for  each  element  of  the  WBS.  The  CBS  supports  the  Planning, 
Programming  and  Budgeting  System  (PPBS)  as  well  as  the  accounting  and 
finance  activities  required  for  appropriated  funds.  A  baseline  cost  estimate, 
organized  in  the  same  manner,  serves  as  the  standard  for  measuring  variances. 
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With  a  WBS  and  a  CBS  defined,  cost  elements  to  the  level  of  detail  required  can 
be  identified  and  tracked  in  a  matrix  similar  to  that  below: 


CBS 


WBS 


$$ 


Figure  A3.7  -  CBSiWBS  MATRIX 
1.4.4  Schedule  Breakdown  Structure  (SBS) 

The  schedule  arm  is  organized  according  to  a  schedule  breakdown  structure 
(SBS)  which  is  also  applied  across  the  WBS.  The  SBS  tracks  key  milestones 
required  by  regulation,  experience,  or  user  needs.  All  activities  conducted  in 
support  of  the  program  will  directly  support  one  or  more  of  these  milestones 
(Figure  A3. 8). 
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Figure  A3, 8 

Example  of  a  Schedule  Breakdown  Structure 


With  an  SBS  defined,  each  element  of  the  WBS  can  now  be  scheduled  resulting  in 
the  following  matrix; 

SBS 


WBS 


Dates 


Figure  A3.9  -  SBStWBS  MATRIX 

The  matrix  of  cost  versus  schedule  could  also  be  developed  at  this  point.  This 
matrix  would  be  useful  for  developing  algorithms  to  estimate  the  cost  impact 
given  a  schedule  change  or  vice-versa.  This  is  the  beginning  of  the 
[cost.’schedule]  transfer  function  in  the  Project  Management  Dynamics  Model. 

1.4.5  Technical  Breakdown  Structure  (TBS) 

The  technical  arm  is  organized  according  to  a  technical  breakdown  structure 
(TBS)  that,  again,  is  applied  across  the  WBS.  The  TBS  identifies  key  performance 
needs  of  the  user  and  allocates  performance  requirements  to  components  of  the 
system  through  the  Work  Breakdown  Structure  (Figure  A3. 10). 
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Figure  A3. 10 

ml^^^CAL  BREAKIX)WN  STRUCTURE  DEVELOPMENT 
BY  WAY  OF  SPECmCATION  AULOCATIONS 
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Now  the  WBS:TBS  matrix  can  be  developed  that  will  contain  the  key 
performance  requirements  of  the  system  or  systems. 


TBS 


WBS 


Performance 

Values 


Figure  A3.11  -  TBS:WBS  MATRIX 

With  the  WBS:TBS  matrix  now  defined,  the  two  remaining  transfer  functions, 
[TBS:SBS]  and  [TBS;CBS],  can  be  determined. 
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